En introduktion til Amazon Fargate: hvad det er, hvorfor det er fantastisk (og ikke), og hvornår man skal bruge det.

Da Amazon annoncerede Fargate i slutningen af ​​2017 på AWS re: Invent (sammen med EKS) faldt det virkelig under radaren. Ingen af ​​de blogs eller influencers, som jeg fulgte på det tidspunkt, talte virkelig om det andet end noget i retning af:

Åh ja, og der er denne nye ting, der giver ECS-brugere mulighed for at køre containere direkte i skyen.

Som udvikler sprængte det mig virkelig. Lad os se hvorfor.

Produktivitetsbommen

Jeg har lyst til, at der har været fem store revolutioner i softwareudviklingsverdenen, der dramatisk øgede udvikleres produktivitet og evne til at skrive og implementere applikationer på produktionsniveau med maksimal effektivitet.

De løste alle også store problemer. Her er min opdeling af revolutioner og de problemer, de løste:

  • Fremkomst af Cloud Services (IaaS)

    Infrastrukturomkostninger og skalerbarhed

  • Open source-samfund, konferencer, workshops, tech-blogs, stackoverløb osv

    Begrænset adgang til viden

  • Versionssystemer, Samarbejdsværktøjer, Kontinuerlige integrationsværktøjer

    Samtidig teknik Systemets uoverensstemmelse og integration helvede

  • Containeriseret arkitektur

    Vanskeligheder med at opbygge applikationer på tværs af inkonsekvente miljøer

  • Serverløse computertjenester (PaaS)

    Servere og systemadministration

Hver eneste af disse revolutioner har et fælles træk: de giver alle mere kontrol til softwareingeniører. De gør dette ved at tilskynde til god praksis og kodedeling med en samarbejdsvillig arbejdsgang, og de mindsker behovet for dyre dedikerede servere, systemadministratorer, DevOps, IT-support osv.

Fantastisk, men vent - hvor er Fargate i alt dette?

Dit skib er problemet

Se, da Docker bragte containere til masserne, blev det hurtigt en ny standard i udvikling og blev bredt vedtaget.

Kort efter og efter Kubernetes succes lancerede AWS deres egen (mere basale) containerhåndteringstjeneste: Amazon Elastic Container Service (ECS). Det introducerede konceptet med opgaver.

En opgave kan være enhver forekomst af containere, der arbejder sammen. Fra en webapplikation, der kører en webserver, flere mikrotjenester, en database og en omvendt proxy til en liste over shell-scriptbatcher, der kører med jævne mellemrum.

At være en tidlig adopterer af ECS, jeg kunne virkelig godt lide det, og det fungerede godt i et stykke tid. Men til sidst blev det mere og mere kompliceret at skulle styre disse ekstra lag (Opgaver og containere) i stedet for kun EC2-forekomster.

Jeg var heller ikke fortrolig med dens sikkerhed . Jo flere lag du har i din stak, jo mere skal du være opmærksom. Hvert af disse lag skaber mere kompleksitet sammen med den øgede sandsynlighed for sikkerhedsfejlkonfigurationer og sårbarheder.

Faktisk kører dine containere med ECS i EC2-containerinstanser i en klynge, som du vil konfigurere til automatisk skalering. Hver forekomst kan være vært for flere forskellige opgaver. Hver opgave kan køre flere containere.

Da dine opgaver vil blive distribueret tilfældigt (som standard) på den samme type EC2-forekomster med tilgængelige ressourcer , står du over for følgende problemer:

  • Én klynge følger de samme regler for automatisk skalering og sørger automatisk for den samme type EC2-forekomster.
  • Nogle containere har brug for helt forskellige ressourcer, men er stadig nødt til at arbejde sammen.
  • Nogle containere følger ikke nødvendigvis de samme regler for autoskalering.
  • Nogle gange har flere containere i samme opgave brug for deres egen load balancer, og det er ikke muligt at have flere load balancere til den samme opgave.

Den foretrukne løsning, når disse problemer blev stillet, var at:

  • manuelt distribuere nogle af dine forekomster med forskellige ressourcer baseret på behov
  • vedhæft disse forekomster til din klynge
  • kør en container efter opgave
  • forbinde dine EC2-forekomster manuelt sammen
  • skriv komplekse strategiplaceringsbegrænsninger på ECS for at sikre, at den rigtige opgave var på den rigtige maskine, der havde den passende ressource afhængigt af hvad den gjorde

Det er meget arbejde, det er ret kedeligt og det er svært at vedligeholde. Og det besejrer formålet med at arbejde med containere i første omgang.

Nogen måtte komme med en bedre idé.

Lad dem flyde

Som det viser sig, havde AWS-teamet de samme problemer. De overvejede det i det forløbne år og arbejdede på at løse problemet nedenfor:

Hvordan kunne vi køre containere uden at skulle bekymre os om servere og klynger?

Og dette er, hvad AWS Fargate handler om . Det abstraherer den underliggende infrastruktur fuldstændigt, og du ser hver eneste af dine containere som en enkelt maskine.

Du skal bare specificere, hvilken ressource du har brug for til hver container, og den løfter tungt for dig. Du behøver ikke længere styre adgangsregler for flere lag. Du kan finjustere tilladelserne mellem dine containere, som du ville gøre mellem enkelte EC2-forekomster.

Det er som om dine containere bliver skibene med deres eget sejl, ror og besætning og er i stand til at flyde til deres destination alene.

Containere som en tjeneste (CaaS)

Jeg tror faktisk, at Containers as a Service (CaaS) er den rigtige PaaS, som udviklere har ventet på i årevis. Det giver udviklere mulighed for at distribuere deres containere direkte i skyen uden at skulle bekymre sig om alt imellem.

Selvfølgelig er der allerede mange teknologier derude, der giver dig mulighed for at køre din kode problemfrit på skyen uden at skulle bekymre dig om skala eller serveradministration (som den fantastiske Heroku , Lambda eller endda på sin egen måde Google app-motor) . Men alle har begrænsninger.

  • Du skal vælge mellem at miste lidt fleksibilitet
  • Du skal holde dig til de understøttede sprog
  • Du kan ikke bruge de understøttede sprog, fordi dit projekt har brug for et oprindeligt bibliotek med lavt niveau, der kun er tilgængeligt på meget specifikke systemer
  • Dit projekt bruger en banebrydende teknologi, der ikke vil være tilgængelig for masserne i de næste par år
  • Nogle af disse platforme er meget (meget) dyre, især når de skaleres op

Fargate (eller CaaS) giver dig det bedste fra begge verdener.

Containeriseret arkitektur giver dig den fleksibilitet og kontrol, du har brug for. Det giver dig mulighed for at bruge enhver form for teknologi, der kører i enhver form for system, du ønsker. Containeraspektet vil sikre, at du har den samme opførsel på hver vært, hvad enten det er et dev, test, iscenesættelse eller prod miljø.

Jeg finder dette punkt kritisk for mange tech startups. Faktisk er nogle gange en af ​​dine konkurrencemæssige fordele brugen af ​​en avanceret teknologi, som du har deltaget i at udvikle, eller smart genbrug af en anden i en helt ny og revolutionerende sammenhæng.

Serverløs implementering giver dig mulighed for at fokusere på at skrive god kode. Ingen klargøring, let skalering.

Grænser

CaaS vs PaaS

Det er rigtigt, at du opgiver nogle seje aspekter af ægte PaaS. Ja, du bliver stadig nødt til manuelt at opdatere dine containers billeder, og nogle gange bliver du nødt til at skrive dine egne Docker-billeder. Dette kan være en kamp i starten, hvis du ikke kender det grundlæggende i systemadministration .

Men det betyder også, at du kan gøre stort set alt hvad du kan tænke på og have fuldstændig fleksibilitet og frihed i de systemer, sprog, værktøjer, biblioteker og versioner, som du vil bruge.

Koste

Lad os indse det, at Cloud-tjenester (IaaS) er dyrere end at have din egen infrastruktur (hvis du kunne skalere den op og ned efter behov). Af samme grund koster det ikke at skulle sørge for, administrere og skalere dine servere. Det er måske ikke den bedste løsning endnu for nogle af dine enkleste brugssager.

Lad os håbe, at de vil arbejde på at nedbringe omkostningerne. Så godt som produktet er, er det svært at retfærdiggøre næsten 4 gange prisen på en EC2-instans på forespørgsel svarende (f.eks. Til t2.medium).

Skal jeg skifte alle mine ECS-opgaver til Fargate?

Ikke endnu. Som nævnt ovenfor vil du i nogle tilfælde mere end tredoble dine omkostninger. Indtil de sænker omkostningerne, kan det være bedre at bruge standard EC2-instanes.

Fargate kan dog være mere fordelagtig for dig i følgende brugssager:

  • Hvis du har problemer med automatisk skalering af dine ECS-opgaver effektivt og ofte ender med en masse ubrugt CPU eller hukommelse . Med Fargate betaler du kun for de ressourcer, du har defineret i dine opgaver .
  • Til dine opgaver, der kører efter behov eller efter en tidsplan og ikke har brug for en dedikeret EC2-forekomst. Med Fargate betaler du kun, når din opgave kører.
  • Til dine opgaver, der har toppe Hukommelse og / eller CPU-brug . Bare fordi det sparer dig tid og besvær med konfigurationen og styringen af ​​sådanne sager.

Bonus

For dem, der foretrækker Kubernetes frem for ECS , vil Fargate snart kunne køre Elastic Container Service for Kubernetes.