Un'introduzione ad Amazon Fargate: che cos'è, perché è fantastico (e non) e quando usarlo.

Quando Amazon ha annunciato Fargate alla fine del 2017 ad AWS re: Invent (insieme a EKS) è caduto davvero sotto il radar. Nessuno dei blog o degli influencer che stavo seguendo in quel momento ne parlava davvero a parte qualcosa sulla falsariga di:

Oh sì, e c'è questa nuova cosa che consentirà agli utenti ECS di eseguire i container direttamente nel cloud.

Come sviluppatore, mi ha davvero sbalordito. Vediamo perché.

Il boom della produttività

Mi sembra che ci siano state cinque grandi rivoluzioni nel mondo dello sviluppo software che hanno aumentato notevolmente la produttività e la capacità degli sviluppatori di scrivere e distribuire applicazioni a livello di produzione con la massima efficienza.

Hanno anche risolto i problemi principali. Ecco la mia ripartizione delle rivoluzioni e dei problemi che hanno risolto:

  • Emersione di servizi cloud (IaaS)

    Costo e scalabilità dell'infrastruttura

  • Community open source, conferenze, workshop, blog tecnici, Stack overflow e così via

    Accesso limitato alla conoscenza

  • Sistemi di controllo delle versioni, strumenti di collaborazione, strumenti di integrazione continua

    Ingegneria concorrente Discrepanze dei sistemi e inferno di integrazione

  • Architettura containerizzata

    Difficoltà nella creazione di applicazioni in ambienti incoerenti

  • Serverless Computing Services (PaaS)

    Amministrazione di server e sistemi

Ognuna di queste rivoluzioni ha una caratteristica comune: tutte danno più controllo agli ingegneri del software. Lo fanno incoraggiando le buone pratiche e la condivisione del codice con un flusso di lavoro collaborativo e riducono la necessità di costosi server dedicati, amministratori di sistema, DevOps, supporto IT e così via.

Fantastico, ma aspetta - dov'è Fargate in tutto questo?

La tua nave è il problema

Vedete, quando Docker ha portato i container alle masse, è diventato rapidamente un nuovo standard in fase di sviluppo ed è stato ampiamente adottato.

Subito dopo, e dopo il successo di Kubernetes , AWS ha lanciato il proprio servizio di gestione dei container (più semplice): Amazon Elastic Container Service (ECS). Ha introdotto il concetto di attività.

Un'attività può essere qualsiasi istanza di contenitori che lavorano insieme. Da un'applicazione Web che esegue un server Web, diversi micro servizi, un database e un proxy inverso, a un elenco di batch di script di shell che verranno eseguiti periodicamente.

Essendo uno dei primi ad adottare ECS, mi è piaciuto molto e ha funzionato alla grande per un po '. Ma alla fine, dover gestire questi livelli extra (attività e contenitori) invece delle sole istanze EC2 è diventato sempre più complicato.

Inoltre non ero a mio agio con la sua sicurezza . Più strati hai nel tuo stack, più devi essere vigile. Ciascuno di questi livelli comporta una maggiore complessità insieme alla maggiore probabilità di errori di configurazione e vulnerabilità della sicurezza.

Infatti, con ECS i tuoi contenitori vengono eseguiti in istanze di contenitori EC2 in un cluster che configurerai per la scalabilità automatica. Ogni istanza può ospitare più attività diverse. Ogni attività può eseguire più contenitori.

Poiché le tue attività verranno distribuite in modo casuale (per impostazione predefinita) sullo stesso tipo di istanze EC2 con risorse disponibili , dovrai affrontare i seguenti problemi:

  • Un cluster segue le stesse regole per la scalabilità automatica e fornisce automaticamente lo stesso tipo di istanze EC2.
  • Alcuni contenitori avranno bisogno di risorse completamente diverse ma dovranno comunque lavorare insieme.
  • Alcuni contenitori non seguono necessariamente le stesse regole per la scalabilità automatica.
  • A volte più container nella stessa attività necessitano del proprio servizio di bilanciamento del carico e non è possibile disporre di più sistemi di bilanciamento del carico per la stessa attività.

La soluzione migliore per affrontare questi problemi era:

  • Distribuisci manualmente alcune delle tue istanze con risorse diverse in base alle necessità
  • collega queste istanze al tuo cluster
  • eseguire un contenitore per attività
  • collega le tue istanze EC2 manualmente insieme
  • scrivere complessi vincoli di posizionamento della strategia su ECS per assicurarsi che l'attività giusta fosse sulla macchina giusta che avesse la risorsa appropriata a seconda di ciò che faceva

Questo è un sacco di lavoro, è piuttosto noioso ed è difficile da mantenere. E in un certo senso sconfigge lo scopo di lavorare con i contenitori in primo luogo.

Qualcuno doveva avere un'idea migliore.

Lasciali galleggiare

A quanto pare, il team AWS ha avuto gli stessi problemi. Ci hanno pensato nell'ultimo anno e hanno lavorato per risolvere il problema di seguito:

Come possiamo eseguire container senza doversi preoccupare di server e cluster?

Ed è questo l'argomento di AWS Fargate . Astrae completamente l'infrastruttura sottostante e vedete ognuno dei vostri contenitori come una singola macchina.

Devi solo specificare quale risorsa ti serve per ogni container e farà il lavoro pesante per te. Non è più necessario gestire le regole di accesso a più livelli. Puoi ottimizzare le autorizzazioni tra i tuoi contenitori come faresti tra singole istanze EC2.

È come se i tuoi container diventassero navi con la propria vela, timone ed equipaggio e fossero in grado di raggiungere la loro destinazione da soli.

Container as a Service (CaaS)

In realtà credo che Containers as a Service (CaaS) sia il vero PaaS che gli sviluppatori aspettavano da anni. Consente agli sviluppatori di distribuire i propri contenitori direttamente nel cloud senza doversi preoccupare di tutto ciò che c'è in mezzo.

Ovviamente ci sono già molte tecnologie là fuori che ti consentono di eseguire il tuo codice senza problemi sul cloud senza doversi preoccupare della scalabilità o dell'amministrazione del server (come il fantastico Heroku , Lambda o anche a modo suo il motore delle app Google) . Ma tutti hanno dei limiti.

  • Devi scegliere tra perdere un po 'di flessibilità
  • Devi attenersi alle lingue supportate
  • Non puoi utilizzare le lingue supportate perché il tuo progetto necessita di una libreria nativa di basso livello disponibile solo su sistemi molto specifici
  • Il tuo progetto utilizza una tecnologia all'avanguardia che non sarà disponibile per le masse nei prossimi anni
  • Alcune di queste piattaforme sono molto (molto) costose, soprattutto durante la scalabilità

Fargate (o CaaS) ti offre il meglio di entrambi i mondi.

L'architettura containerizzata ti offre la flessibilità e il controllo di cui hai bisogno. Ti consente di utilizzare qualsiasi tipo di tecnologia in esecuzione in qualsiasi tipo di sistema desideri. L'aspetto del contenitore garantirà lo stesso comportamento su ogni host, che si tratti di un ambiente di sviluppo, test, staging o prod.

Trovo questo punto critico per molte startup tecnologiche. In effetti, a volte uno dei tuoi vantaggi competitivi è l'uso di una tecnologia all'avanguardia che hai partecipato allo sviluppo, o il riutilizzo intelligente di un'altra in un contesto totalmente nuovo e rivoluzionario.

La distribuzione senza server ti consente di concentrarti sulla scrittura di codice eccezionale. Nessun provisioning, facile scalabilità.

Limiti

CaaS vs PaaS

È vero che stai rinunciando ad alcuni aspetti interessanti del vero PaaS. Sì, dovrai comunque aggiornare manualmente le immagini del contenitore e, a volte, dovrai scrivere le tue immagini Docker. All'inizio può essere difficile se non si conoscono le basi dell'amministrazione del sistema .

Ma significa anche che puoi fare praticamente tutto ciò a cui puoi pensare e avere completa flessibilità e libertà nei sistemi, nelle lingue, negli strumenti, nelle librerie e nelle versioni che desideri utilizzare.

Costo

Ammettiamolo, i servizi cloud (IaaS) sono più costosi rispetto alla propria infrastruttura (se si potesse scalarla su e giù su richiesta). Per lo stesso motivo, non dover eseguire il provisioning, gestire e ridimensionare i server ha un costo. Potrebbe non essere ancora la soluzione migliore per alcuni dei tuoi casi d'uso più semplici.

Speriamo che lavorino per ridurre i costi. Per quanto il prodotto sia buono, è difficile giustificare quasi 4 volte il prezzo di un'istanza EC2 equivalente su richiesta (per t2.medium ad esempio).

Devo trasferire tutte le mie attività ECS a Fargate?

Non ancora. Come affermato sopra, in alcuni casi i costi saranno più che triplicati. Fino a quando non riducono il costo, potrebbe essere meglio utilizzare le installazioni EC2 standard.

Tuttavia, Fargate potrebbe essere più vantaggioso per te nei seguenti casi d'uso:

  • In caso di problemi con il ridimensionamento automatico delle attività ECS in modo efficiente e spesso si finisce con molta CPU o memoria inutilizzata . Con Fargate, paghi solo per le risorse che hai definito nelle tue attività .
  • Per le tue attività che verranno eseguite su richiesta o in base a una pianificazione e non necessitano di un'istanza EC2 dedicata. Con Fargate, paghi solo quando l'attività è in esecuzione.
  • Per le tue attività che hanno picchi di utilizzo della memoria e / o della CPU . Solo perché ti farà risparmiare tempo e fatica nella configurazione e nella gestione di tali casi.

Bonus

Per coloro che preferiscono Kubernetes a ECS , Fargate sarà presto in grado di eseguire Elastic Container Service per Kubernetes.