EKS vs ECS: differenze inattese e consigli pratici per scegliere bene

Capire se EKS o ECS sia la soluzione più adatta a un progetto non è sempre semplice.

Se si ragiona sulle singole caratteristiche, individuare un vincitore netto è facile. La difficoltà nasce dal fatto che, per fare un confronto valido, occorre considerare ciascun prodotto come un insieme di caratteristiche: è quindi più corretto vederli entrambi come un compromesso fatto di pro e contro che convivono.

Una volta compreso questo, ne derivano due conseguenze naturali:

1. Nessuna delle due opzioni è la migliore in assoluto. La scelta più adatta dipende dai requisiti e dai vincoli del progetto e dell'organizzazione.

2. Per stabilire in modo oggettivo quale sia la soluzione più adatta a un progetto serve una buona dose di pensiero critico e di ragionamento articolato.

In questo articolo troverà differenze, implicazioni e considerazioni raramente documentate, rilevanti rispetto ai vincoli più comuni a livello di progetto e di organizzazione, oltre ad altri fattori che vale la pena valutare al momento della scelta.

Conviene leggere questo contenuto come un ragionamento guidato basato su consigli condizionali che, applicati a un progetto specifico, si trasformano rapidamente in indicazioni pratiche utili a prendere una decisione ben ponderata.

BLUF (Bottom Line Up Front)

Indice

Pubblico di riferimento

Introduzione

Sezione 1: differenze minori tra EKS ed ECS

1. ECS ha prezzi Fargate decisamente migliori (Fargate su EKS è costoso).

2. La densità di container su EC2 di EKS è nettamente superiore a quella di ECS.

3. ECS offre opzioni di service discovery più avanzate.

4. EKS ha un leggero vantaggio rispetto a ECS in termini di multicloud e sviluppo locale, dato che si basa su Kubernetes.

5. ECS non addebita i costi del control plane, mentre EKS sì.

Sezione 2: considerazioni su differenze potenzialmente critiche

1. EKS offre uno scaling dei container più rapido per impostazione predefinita e un supporto avanzato per l'autoscaling, quando si utilizza un add-on come keda.sh.

2. L'IaC (Infrastructure as Code) di EKS è strutturalmente superiore a quella di ECS, perché è standardizzata, leggibile, disaccoppiata, dichiarativa e supporta metadati con stato.

3. ECS non ha un supporto nativo per i volumi.

4. Il livello di difficoltà di EKS tende a essere variabile e paradossale:

"EKS tende a essere difficile perché è troppo facile."

5. Gli aggiornamenti di ECS sono estremamente rari, e questo è un grande vantaggio in termini di stabilità e di riduzione del lavoro ripetitivo legato alle operazioni di cluster.

6. EKS comporta un overhead di manutenzione inevitabile e un ordine di grandezza in più di componenti rispetto a ECS, che non richiede mai manutenzione.

Sezione 3: regole pratiche per scegliere ECS, EKS o nessuno dei due.

1. ECS può essere la scelta migliore negli scenari in cui:

2. Giustificare oggettivamente EKS come la scelta migliore richiede una riflessione un po' più approfondita sui fattori contestuali: (questa sezione contiene anche utili indicazioni su EKS Auto Mode.)

3. Le applicazioni stateful sono uno scenario abbastanza diffuso da meritare una discussione basata su regole pratiche:

Conclusione

Questo articolo è rivolto a chi vuole capire come prendere una decisione ben ponderata nella scelta tra EKS ed ECS.

Se rientra in questo pubblico, leggere un articolo relativamente lungo come questo varrà il suo tempo: al termine sarà nelle condizioni ideali per raggiungere l'obiettivo principale, ovvero prendere una decisione ben argomentata, e i tre obiettivi ausiliari seguenti:

1. Scoprire differenze, pro e contro inaspettati.

(Mi concentrerò su quelli difficili da trovare con una ricerca su Google e spesso non documentati.)

2. Apprendere i metadati decisionali.

(Ad esempio le implicazioni concrete delle scelte e gli insight sui fattori critici e sui vincoli più frequenti, che vale la pena soppesare con attenzione nella valutazione delle opzioni. Sono anche ottimi candidati per la definizione di regole pratiche.)

3. Comprendere il ragionamento alla base delle affermazioni.

Se riesce a comprendere, condividere e parafrasare il ragionamento e le motivazioni che dimostrano la validità di affermazioni, implicazioni o insight, può sfruttare quella conoscenza per consolidare la fiducia (a livello personale, di team o di organizzazione) nel fatto che una decisione sia sensata e fondata su argomentazioni valide.

Il resto dell'articolo è suddiviso in sezioni che corrispondono all'indice riportato sopra. Ogni sezione contiene un elenco di affermazioni accompagnate da un mix di chiarimenti, evidenze fattuali ed elementi aneddotici utili a sostenerne la validità.

La prima sezione presenta un elenco numerato di differenze specifiche tra EKS ed ECS, utili da conoscere ma di norma poco rilevanti.

La seconda sezione approfondisce differenze a cui vale la pena prestare attenzione, perché possono rivelarsi fattori critici nelle decisioni.

La terza sezione propone regole pratiche condizionali basate sulle problematiche più comuni a livello di progetto, team o organizzazione. Combinandole con le sue specifiche circostanze, è possibile ricavarne consigli operativi.

Sia ECS sia EKS possono essere supportati da Fargate o da EC2. Ciò detto, ECS tende fortemente a usare Fargate, mentre EKS tende a usare istanze EC2.

Le prime due differenze di questa sezione evidenziano un punto di forza di ciascuno che spiega il senso di questa tendenza. Le tre successive descrivono vantaggi minori, accompagnati dalle ragioni per cui sono relativamente trascurabili.

1. ECS ha prezzi Fargate decisamente migliori (Fargate su EKS è costoso).

È un aspetto di importanza minore, perché, indipendentemente dal prezzo, gli utenti di EKS potrebbero comunque preferire EC2 per i suoi vantaggi funzionali. (EC2 supporta la cache delle immagini dei container e i daemonset, mentre Fargate no.)

• In teoria, secondo la documentazione di AWS Fargate, le istanze Fargate dovrebbero costare leggermente di più rispetto a EC2 in cambio di vantaggi in termini di praticità e sicurezza, e questo trade-off mira a ridurre il costo totale di proprietà.

Nella realtà, questa interpretazione vale solo per ECS, perché ECS supporta istanze Fargate basate su AMD (ovvero Intel/x86_64), ARM, on-demand e Spot.

• EKS supporta solo istanze Fargate on-demand basate su AMD.

EKS non supporta né le " Fargate spot instances" né " Fargate basato su ARM".

• Ciò significa che, nel confronto dei costi per EKS, deve raffrontare l'opzione più costosa con la meno costosa E gestire la logica di arrotondamento delle dimensioni delle istanze Fargate, che si somma ai costi extra.
• Per fare un esempio concreto, supponiamo che un container sia stato sottoposto ad analisi di right-sizing, da cui risulti che funziona meglio con 1,8 CPU e 1,2 GB di RAM.

Se servono 2 CPU, Fargate arrotonda automaticamente a 4 GB di RAM e si deve usare il prezzo Fargate on-demand basato su AMD. Nella regione us-east-1 il prezzo di Fargate è di 2,37 $/giorno. Questo container starebbe comodamente su un nodo Spot EC2 EKS basato su ARM di tipo t4g.small, che costerebbe 0,1512 $/giorno.

• Quindi EKS con Fargate può costare fino a 15 volte di più rispetto a EKS con EC2! (Vale anche la pena sottolineare che questo confronto si basa sulla regione più economica; nelle regioni più costose la differenza di 15x è ancora più alta!)

2. La densità di container su EC2 di EKS è nettamente superiore a quella di ECS.

Nota: se la maggior parte dei suoi container utilizza almeno 1 CPU e 1 GB di RAM, la differenza di prezzo sarà minima, perché t3/t4g.small può ospitare 2 task ECS di queste dimensioni.

Se distribuisce un gran numero di microservizi con basso utilizzo di CPU e RAM, eseguirli su EKS può essere notevolmente più economico, grazie alla maggiore densità di container offerta da EKS . (Nota: per le organizzazioni che effettuano deployment su larga scala di numerosi microservizi questo può rappresentare un fattore di risparmio significativo, ma per la maggior parte delle organizzazioni la differenza di costo non sarebbe particolarmente rilevante: la considero quindi una differenza minore.)

• Molti utenti di ECS tendono a usare istanze Fargate, che comunque consentono un solo task/pod per istanza. Quello che spesso si ignora è che ECS su EC2 è significativamente peggiore di EKS su EC2.
• Un t4g.small può eseguire 11 pod EKS oppure 2 task ECS.

Un t4g.large può eseguire 35 pod EKS oppure 2 task ECS.

• L'ho calcolato usando:

aws ec2 describe-instance-types \
--filters "Name=instance-type,Values=t4g.*" \
--query "InstanceTypes[].{Type: InstanceType, MaxENI: NetworkInfo.MaximumNetworkInterfaces, IPv4addr: NetworkInfo.Ipv4AddressesPerInterface}" \
--output table

• L'output del comando mostra che t4g.small supporta 3 ENI. ECS ne usa 1 per la VM host, poi ne assegna 1 per ciascun task. Una buona formula sintetica è $MAX_ENI -1 = $MAX_TASKS_PER_EC2_INSTANCE. (3-1=2).
• Nota: ECS dispone di una funzionalità dal nome poco felice chiamata ENI trunking (alias AWS VPC Trunking). In teoria dovrebbe aumentare la densità di container di ECS, ma in pratica è supportata solo da tipi di istanza che, dal punto di vista dell'ottimizzazione dei costi FinOps, non hanno MAI senso, quindi le consiglio di fare semplicemente finta che non esista.
• Alcune note correlate interessanti:

Di norma, le istanze AMD sono la scelta migliore per impostazione predefinita, grazie a costi inferiori e prestazioni superiori. La "a" in t3a sta per AMD, quindi come regola generale t3a è meglio di t3; tuttavia, la densità di container di ECS è uno dei rari casi in cui t3 batte t3a: t3a.small ha stranamente solo 2 ENI e supporta quindi un solo task ECS, mentre t3.small ha 3 ENI e ne supporta 2.

• I 2 motivi principali per cui, a mio avviso, gli utenti di ECS preferiscono le istanze Fargate sono:

1. Configurare ECS con Fargate è praticamente turnkey, mentre ECS su EC2 richiede del lavoro aggiuntivo.

2. L'assenza di una densità di container nettamente superiore sulle istanze EC2 riduce l'incentivo a passare da ECS con Fargate a ECS con EC2.

3. ECS offre opzioni di service discovery più avanzate.

La considero un vantaggio minore di ECS, perché si rivela utile solo in casi d'uso rari e, in tali casi, EKS può ottenere risultati simili installando strumenti opzionali per estendere la funzionalità di base.

• La service discovery di EKS si basa su Inner Cluster DNS Names, risolvibili solo dai pod all'interno del cluster, che seguono un pattern prevedibile del tipo $SERVICE.$NAMESPACE.svc.cluster.local
• ECS offre due opzioni di service discovery. Una è basata su API e supporta le comunicazioni interne al cluster ECS; l'altra è basata su DNS e supporta le comunicazioni interne alla VPC. ( Se è interessato, può approfondire qui.)

4. EKS ha un leggero vantaggio rispetto a ECS in termini di multicloud e sviluppo locale, dato che si basa su Kubernetes.

Ecco perché questa differenza è relativamente trascurabile:

• Il multicloud è quasi sempre una pessima idea; l'unico modo per realizzarlo correttamente è adottare un design cloud-agnostic, che a sua volta è raramente una buona idea. Il problema principale del multicloud è che, in pratica, è facile incontrare 10 problemi reali per ogni 1 beneficio teorico.
• Minikube e Rancher Desktop possono essere usati per eseguire Kubernetes in locale, ma in pratica ho visto solo singoli engineer altamente qualificati trarne vantaggio implementandolo manualmente sul proprio laptop.

Esistono molte sfumature legate alle integrazioni che rendono proibitivo offrire un'esperienza di sviluppo locale coerente e ricca di integrazioni utili a livello di team senza un investimento significativo. Quindi, in realtà, il valore pratico di questo vantaggio tende a essere molto limitato.

• Poiché ECS è basato su Docker, gli engineer altamente qualificati possono fare sviluppo locale basato su Docker sui propri laptop. Lo sviluppo locale basato su Docker è parzialmente applicabile a ECS, esattamente come Kubernetes locale lo è per EKS.

Allo stesso modo, dato che solo gli engineer altamente qualificati riescono a gestire le sfumature delle integrazioni per ottenere benefici che si applicano solo a loro come singoli sviluppatori, anche per ECS l'essere basato su Docker tende ad avere un valore pratico limitato.

5. ECS non addebita i costi del control plane, mentre EKS sì.

Lo considero un vantaggio relativamente minore, perché i costi di EKS sono molto contenuti e facili da giustificare. Ciò detto, capisco che possa contare per una startup che deve operare al minor costo possibile.

• Se mantiene il cluster EKS aggiornato, il costo è di 864 $/anno per cluster. Detto questo, è prassi comune avere un cluster di dev, uno di stage, uno di prod e qualche cluster sandbox temporaneo, quindi una stima più realistica è 3.000 $/anno.
• Ecco 3 motivi per cui i costi del control plane di EKS sono facili da giustificare:
• 1. Hanno senso a prescindere da ECS.

Se provasse a far girare una distribuzione Kubernetes cloud-agnostic come Talos o Rancher, dovrebbe pagare 3 VM da usare come nodi di control plane HA/FT. I costi del control plane di EKS sono inferiori all'opzione DIY e, in più, offrono i vantaggi di un servizio gestito.

• 2. EKS offre funzionalità per cui vale la pena pagare un piccolo sovrapprezzo, soprattutto in termini di maggiore facilità di debug e di cicli di feedback più rapidi. (La sezione successiva approfondisce questo aspetto.)
• 3. EKS dispone di funzionalità di risparmio proprie: EKS su EC2 è più economico di ECS con Fargate ed è potenzialmente più economico anche di ECS su EC2 grazie alla maggiore densità di container; Kubernetes Ingress facilita la configurazione di load balancer condivisi tra più servizi, riducendo il numero di LB AWS da pagare; karpenter.sh offre autoscaling automatico e right-sized; keda.sh offre autoscaling avanzato dei container.
• Tutto ciò può portare EKS ad avere un costo di hosting inferiore a ECS. Le variabili condizionali in gioco sono troppe per affermare che uno tenda ad essere più economico, ma è vero che non è raro che EKS risulti complessivamente più economico o che la differenza netta sia trascurabile, e questo rende il costo del control plane EKS un punto potenzialmente irrilevante.

Questa sezione illustra tre punti di forza di EKS, un paradosso di EKS che tende a essere uno svantaggio ma può rivelarsi un vantaggio, seguiti da due punti di forza di ECS.

1. EKS offre uno scaling dei container più rapido per impostazione predefinita e un supporto avanzato per l'autoscaling, quando si utilizza un add-on come keda.sh.

• In generale, EKS tende a scalare verso l'alto più rapidamente di ECS. Confrontando EKS su EC2 con ECS su Fargate la cosa è intuitiva, dato che Fargate non supporta la cache delle immagini dei container.

Ciò che è meno intuitivo è che EKS tende a produrre tempi di avvio rapidi più di frequente anche quando sia EKS sia ECS sono basati su istanze EC2.

Questo perché EKS ha una densità di container più elevata, che gli consente di sfruttare più spesso la cache delle immagini dei container. Grazie alla cache delle immagini, non è raro che un pod EKS si avvii nel giro di pochi secondi.

• ECS supporta bene l'autoscaling e consente di scalare in base a metriche CloudWatch personalizzate, ma non è all'altezza di EKS quando si tratta di scaling. EKS è notevolmente più rapido ed efficace nell'autoscaling dei container, grazie ad alcune sfumature legate ai dettagli implementativi di ECS, alla risoluzione delle metriche e al supporto allo scaling a 0.
• Approfondisco i dettagli implementativi problematici di ECS. L'autoscaling target-based può scalare verso l'alto solo per un numero fisso di unità di capacità; offre una seconda opzione di autoscaling step-based per consentire un certo grado di scaling variabile, ma tra una decisione di scaling e l'altra si verifica un ritardo di 1 minuto, perché i data point delle metriche vengono raccolti una volta al minuto.
• (La frequenza di raccolta delle metriche è spesso definita risoluzione delle metriche.)
• EKS utilizza l' HPA (Horizontal Pod Autoscaler) di Kubernetes, che ha una risoluzione delle metriche predefinita di 15 secondi, quindi può scalare 4 volte prima.
• Lo scaling di ECS si basa su CloudWatch Metrics, CloudWatch Alarms e su un mix di valori predefiniti subottimali e non modificabili, che lo rendono complessivamente meno valido delle opzioni HPA di EKS.

ECS ha uno scenario nel migliore dei casi in cui può battere EKS sotto un aspetto, in cambio di pessimi compromessi, ma nel complesso le sue opzioni non sono altrettanto valide.

• Ecco come si presenta lo scenario migliore di autoscaling basato sulle metriche di ECS:

Una metrica CloudWatch personalizzata ad alta risoluzione può avere una risoluzione fino a 1 secondo.

In realtà conta solo ogni 10 secondi, perché lo scaling è innescato dall'allarme CloudWatch, che ha un periodo di valutazione minimo di 10 secondi.

Tecnicamente, questo batte il periodo di valutazione predefinito (e non modificabile) di 15 secondi dell'HPA di EKS, ma il vantaggio è accompagnato da un pessimo compromesso. Se implementa una risoluzione delle metriche di 10 secondi (in realtà, qualunque valore inferiore al minuto), avrà solo 3 ore di retention delle metriche.

• Ecco come si presenta in genere l'autoscaling basato sulle metriche di ECS negli scenari più comuni:
• Le metriche di CPU e RAM di ECS hanno una risoluzione di 1 minuto, valore predefinito non modificabile, e questo costringe il periodo di valutazione minimo dell'allarme CloudWatch a essere di 1 minuto nei casi più comuni.
• Anche se implementa una metrica personalizzata, potrebbe scegliere di rilevarla una volta al minuto per avere 15 giorni di retention e un costo inferiore.
• Vale anche la pena sottolineare che la risoluzione delle metriche di ECS ha un valore predefinito implicito di 1 minuto e richiede una configurazione esplicita per abilitare la granularità di 10 secondi.

Il metrics server di Kubernetes ha un valore predefinito implicito di risoluzione delle metriche migliore, pari a 15 secondi.

• ECS può scalare a 0 solo quando si utilizzano le metriche delle code SQS; in condizioni normali non può scalare a 0.
• EKS può installare un add-on gratuito chiamato keda.sh per abilitare funzionalità di autoscaling più robuste, come metriche personalizzate, scaling del traffico HTTP a 0 e scaling basato su cron.

L'opzione cron è particolarmente utile nello scenario comune in cui serve capacità di base aggiuntiva oltre all'autoscaling, per gestire in modo fluido i picchi di traffico durante le ore lavorative di punta e permettere alla capacità di base di ridursi durante i periodi prevedibili di bassa attività.

2. L'IaC (Infrastructure as Code) di EKS è strutturalmente superiore a quella di ECS, perché è standardizzata, leggibile, disaccoppiata, dichiarativa e supporta metadati con stato.

Queste caratteristiche generano vantaggi di diversi ordini di grandezza in termini di facilità di debug, cicli di feedback ed esperienza utente DevOps complessiva.

• EKS segue lo standard Kubernetes basato su kubectl + YAML.

È rapido e semplice da leggere, apprendere e modificare. (Il supporto intrinseco di YAML al JSON è un ulteriore vantaggio, dato che YAML è un superset di JSON.)

• ECS, di fatto, non ha uno standard ufficiale, sia in termini di IaC sia di tooling. Questo rende l'IaC di ECS più difficile da apprendere, perché ci si trova subito a dover studiare e scegliere tra le opzioni di tooling più comuni: AWS Copilot, AWS CDK, Terraform o Pulumi.
• In termini di opzioni di IaC e tooling, EKS ne offre di più, ma in termini di standard ce n'è uno solo. Inoltre, tutte le opzioni di EKS si basano su quell'unico standard; ciò gli conferisce un vantaggio significativo sia in termini di facilità di apprendimento sia di probabilità di sviluppare competenze trasferibili tra datori di lavoro che preferiscono adottare standard comuni.
• La mancanza di disaccoppiamento concettuale e di IaC in ECS comporta diversi svantaggi intrinseci.

Un ECS Service equivale concettualmente a un deployment, service, configmap, secret e ruolo IAM AWS di EKS strettamente accoppiati in un unico bundle. Questo crea diversi problemi:

• 1. Un problema è che lo stretto accoppiamento dei deployment in ECS impone limiti alle modifiche in-place che si possono apportare a un oggetto già distribuito.

Non è raro che le modifiche richiedano redeploy completi o fastidiosi processi in due fasi, con cancellazione e ricreazione.

La cosa diventa noiosa molto in fretta quando si devono apportare modifiche iterative.

Con ECS aggiungere, rimuovere o cambiare il tipo di load balancer è molto fastidioso. Scoprirà di non poter riutilizzare lo stesso nome del servizio senza eliminarlo e ricrearlo da zero, con il rischio di causare downtime. Si può aggirare il problema con un cutover blue-green, ma comporta overhead.

Gli engineer che interagiscono con EKS, invece, vivono un'ottima esperienza grazie ad aggiornamenti dichiarativi e idempotenti.

• 2. I deployment di ECS sono per loro natura più lenti di quelli di EKS.
• 3. Quando un deployment ECS va male, è facile ritrovarsi a fare il debug di una black box, senza segnali chiari che indichino se lo stato effettivo è convergente verso quello desiderato.

Quindi non è raro che gli engineer di ECS debbano attendere i timeout e impiegare circa 4 minuti tra un'iterazione e l'altra per ottenere un "il computer dice no".

Alcune scelte di tooling come AWS Copilot possono peggiorare ulteriormente l'esperienza black box. Quando Copilot incappa in determinati scenari di debug, il tempo di attesa tra le iterazioni può spesso arrivare a 20-60 minuti, perché bisogna attendere il timeout di ECS, CloudFormation e di altri livelli di astrazione black box.

Non dimentichiamo che, quando si verificano errori, la natura black box di ECS spesso non fornisce feedback né indizi sulla causa.

• 4. Il debug dei problemi nei deployment ECS tende a richiedere più iterazioni rispetto al debug degli oggetti YAML di EKS, che sono più semplici e disaccoppiabili.

Questa tendenza si verifica perché i task ECS sono un bundle strettamente accoppiato di più componenti; lo scope del troubleshooting è più ampio e non c'è un modo semplice per restringere il campo a un componente specifico.

• Quando arriva il momento di fare debug su EKS, è facile distribuire, modificare e debuggare i componenti in modo sistematico e indipendente l'uno dall'altro. Ed è facile arrivare a un ciclo di feedback misurato in secondi, perché si hanno segnali chiari quando si esegue un kubectl describe o un comando di output YAML e si guardano gli eventi e lo stato di un oggetto YAML. Il ciclo di feedback di EKS tende a essere limitato dalla velocità con cui si pensa e si scrive.
• Grazie a kubectl port-forward, è banalmente facile fare debug di servizi con IP privati su EKS. ECS non ha un equivalente reale.
• Un elemento essenziale dell'ottima esperienza utente di Kubernetes in termini di feedback è che i controller aggiungono metadati con stato ai manifest YAML degli oggetti dei componenti applicati con kubectl al database etcd di un cluster live.

Grazie a questo, gli engineer possono usare kubectl describe e i comandi di output YAML per visualizzare i metadati relativi a eventi o stato di un oggetto; ne deriva un feedback rapido e spesso specifico sul successo o il fallimento delle varie fasi nei singoli oggetti dei componenti.

Quindi, quando qualcosa va storto, si può rapidamente capire con sicurezza quale singolo componente ha fallito e cosa è andato storto.

• Confrontiamo questo con il workflow rotto di ECS: la GUI web di AWS le permette di creare un servizio ECS di tipo load balancer, e il questionario di deployment della GUI le chiederà su quali subnet vuole effettuare il deployment.

Le dirà che non può effettuare il deployment sia su subnet pubbliche sia private e che deve sceglierne una, ma non le fornisce un dettaglio fondamentale della domanda:

Si tratta delle subnet per il load balancer o delle subnet per le istanze backend?

Inoltre, chiede di scegliere le subnet una sola volta, quando dovrebbe chiederlo due volte per consentirle di seguire la best practice standard di rendere il load balancer pubblico e le istanze backend private.

Il workflow di ECS le permette di fare cose che dovrebbe essere programmato per impedire, come distribuire un load balancer con IP pubblico in una subnet privata.

Ovviamente non funzionerà, e dovrebbe essere intercettato dalla validazione degli input; invece, riceverà un errore evitabile accompagnato da un feedback scarso sulle ragioni del malfunzionamento.

• Un altro scenario di debug comune in cui EKS brilla:

Supponiamo che un engineer crei una nuova VPC per fare dei test e poi distribuisca per errore un cluster EKS o ECS in una VPC priva di NAT gateway.

• Con ECS otterrà zero log e zero metriche, perché il pull dell'immagine del container fallirà per mancanza di accesso a Internet. Il fatto è che andrà alla cieca, senza alcun feedback su cosa è andato storto. ECS exec non è integrato in modo turnkey nella piattaforma né attivo per impostazione predefinita; al contrario, è difficile da abilitare.

È facile sprecare molte iterazioni a debuggare inutilmente la configurazione del task o del servizio ECS senza rendersi conto che il problema è nella VPC, perché ECS è più una black box con feedback scarso.

Non c'è nemmeno qualcosa che le dica che il pull dell'immagine è fallito; è costretto a intuire che debba essere quella la causa del problema.

• Se si imbatte nello stesso scenario problematico con EKS, è molto più facile risolverlo, perché anche se i nodi worker non hanno accesso a Internet, il control plane è raggiungibile pubblicamente per impostazione predefinita; può quindi usare kubectl per ottenere feedback come image pull failed, che è un buon indizio della mancanza di connettività Internet.

3. ECS non ha un supporto nativo per i volumi.

• Una cosa che mi ha sorpreso scoprire su ECS è che, se vuole iniettare configurazioni o un secret (da una config in-line in un file ecs-task-definition.json o referenziato da AWS Secrets Manager), le variabili d'ambiente sono l'unica opzione ufficiale integrata in ECS per caricare la configurazione. Non esiste un'opzione semplice e integrata nella piattaforma ECS per montare configurazioni o secret come file.
• Questa incapacità di iniettare facilmente file di configurazione dinamici è uno dei motivi principali per cui ECS non ha un equivalente del concetto Kubernetes di Ingress Controller.
• ECS può usare EFS per lo storage stateful ed esistono soluzioni di ripiego per montare file, ma il punto è che si tratta di metodi forzati, non semplici da implementare, perché non c'è alcun supporto per i volumi integrato a livello di piattaforma ECS.

C'è una sfumatura che vale la pena chiarire su questa affermazione:

ECS ha supporto a livello di piattaforma AWS per EFS, ma non ci sono integrazioni a livello di piattaforma ECS che ne semplifichino la configurazione.

(Non solo non è semplice: direi che è spesso più difficile configurare EFS su ECS rispetto a configurarlo su EC2 standalone o EKS, perché ECS tende a comportarsi come una black box difficile da debuggare e con un ciclo di feedback lento.)

• EKS, invece, dispone di un driver CSI EFS per configurare una Storage Class Kubernetes; questa integrazione e il supporto integrato a livello di piattaforma EKS possono semplificare la configurazione di EFS su EKS.)
• In EKS configurazioni e secret possono essere montati sia come variabili d'ambiente sia come file. Statefulset, storage class, persistent volume e altre funzionalità avanzate rendono relativamente semplice implementare workloads stateful.

4. Il livello di difficoltà di EKS tende a essere variabile e paradossale: "EKS tende a essere difficile perché è troppo facile."

Il livello di difficoltà di ECS è relativamente statico, perché ECS ha vincoli più strutturali. Il senso di queste sfumature è che, quando un team di implementazione ha accesso a una consulenza esperta basata sull'esperienza e adotta una buona strategia implementativa, EKS può risultare più semplice di ECS.

(Per chi non lo sapesse, è un punto di vista basato sul pensiero critico che si oppone a un'affermazione comune nei documenti AWS, ovvero che ECS sia sempre più semplice di EKS.)

• Mi segua per un attimo, perché spiegare questo insight richiede tempo: comporta sfumature, un paradosso empirico e la condivisione di alcuni ragionamenti essenziali per rendere intuitivo l'insight che segue:
• EKS ha il potenziale di essere più semplice di ECS. ECS ha svantaggi intrinseci e inevitabili; quelli più importanti sono già stati menzionati in precedenza. Gli svantaggi di EKS sono fondamentalmente diversi, perché tendono a essere una proprietà emergente che nasce da un paradosso causato da bias naturali.

Se comprende il quadro generale dello svantaggio paradossale di EKS, le sue cause e come evitarlo strategicamente, EKS diventa molto più semplice.

• EKS è un ottimo esempio di un vecchio adagio: "Si può avere troppo di una cosa buona. Quando le cose buone vengono portate all'estremo, spesso danno origine a problemi."
• Kubernetes è troppo buono, troppo capace e ha avuto un successo così travolgente da generare un ecosistema enorme. Quell'ecosistema enorme è complesso, e quella complessità, abbinata al bias naturale ad adottare strumenti Kubernetes con benefici evidenti ma costi nascosti, è una delle ragioni principali per cui EKS viene percepito come difficile.
• Una presa di coscienza importante è che il grande, complesso ecosistema di Kubernetes è tutto opzionale. Se sceglie strategicamente di limitarne l'uso, EKS resta semplice.
• Le do un po' di contesto, e poi affronto un altro paradosso correlato:
• Una delle competenze ingegneristiche di livello principal che possiedo è la capacità di distinguere tra problem solver e problem transformer. I problem transformer sono strumenti e tecniche che risolvono 1 problema in cambio della creazione di N nuovi problemi, e tendono a essere cattive idee da evitare, a meno che non sappia davvero cosa sta facendo e non abbia ragionato sulle varie conseguenze di secondo ordine.
• È questa la logica per cui ritengo che le seguenti tendano a essere cattive idee:

Operatori Kubernetes, Statefulset, l'uso di API non v1, gli operatori che distribuiscono Statefulset usando API alpha (uno dei casi peggiori), service mesh e nginx-ingress controller. Non possiamo dimenticare HashiCorp Vault: "Friends don't let friends use hashi-vault".

• Alcuni esempi di problemi introdotti sono CVE critiche, overhead di manutenzione e aggiornamenti forzati di EKS che alla fine portano ad aggiornamenti forzati delle applicazioni.

Non è raro che gli aggiornamenti introducano breaking change e, di conseguenza, ci sono nuovi modi in cui i suoi servizi possono andare in errore e un raggio d'azione (blast radius) maggiore in caso di problema, il che significa che le serviranno più test.

• Una configurazione sufficientemente complessa può creare problemi legati a IaC, automazione, documentazione, colli di bottiglia di competenze, questioni di staffing e altro ancora.
• Con questo contesto in mente, ecco il paradosso correlato:

Se qualcuno ha una cattiva idea, ECS è restrittivo, poco flessibile e abbastanza difficile da rendere subito evidente che una cattiva idea sarà difficile da implementare. Sarà già abbastanza difficile fare il minimo indispensabile, quindi ci si limiterà al minimo indispensabile, e di conseguenza ECS tende a essere visto come più semplice.

• EKS, di nuovo, è troppo flessibile e troppo capace per il suo bene.

Quando qualcuno propone una cattiva idea, EKS offre talmente tanta libertà e facilità di implementazione che qualunque idea può essere realizzata, comprese quelle cattive.

È un peccato che le cattive idee vengano condivise, perché Kubernetes è così facile da usare che gli altri possono adottarle e implementarle senza accorgersi che sono cattive.

Poi, quando emergono i problemi, è Kubernetes a prendersi le critiche per essere troppo difficile.

La verità nascosta è che molti problemi possono essere evitati semplicemente evitando le cattive idee.

O detto in altro modo: "EKS è difficile quando le persone lo rendono difficile."

• Le considerazioni precedenti possono essere combinate per costituire la base di una buona strategia di implementazione di EKS:

In sostanza, cerchi di attenersi alle funzionalità EKS più semplici applicando una regola pratica: preferire le funzionalità integrate, considerare regolarmente il principio YAGNI ed evitare funzionalità non disponibili in ECS. (ECS, di fatto, non ha operatori, ingress controller, persistent volume, API non stabili, un ecosistema enorme di strumenti di terze parti, e il supporto ad AWS App Mesh è in fase di rimozione.)

Se confronta i due con questa strategia in mente, si avvicina a un confronto alla pari; e a quel punto EKS inizia a sembrare una croccante e gustosa Honeycrisp.

5. Gli aggiornamenti di ECS sono estremamente rari, e questo è un grande vantaggio in termini di stabilità e di riduzione del lavoro ripetitivo legato alle operazioni di cluster.

• In teoria, un'istanza Fargate on-demand può restare anni senza essere aggiornata; questo evita disservizi causati da breaking change associati agli aggiornamenti.
• La piattaforma EKS, prima o poi, costringe gli adopter ad aggiornare e, se le applicazioni in esecuzione sul cluster sono state trascurate e mai aggiornate, c'è il rischio che un aggiornamento forzato della piattaforma rompa versioni obsolete di applicazioni progettate per funzionare con versioni specifiche di Kubernetes.
• Il nginx-ingress controller è un buon esempio di applicazione molto nota che ha una tabella che elenca le versioni specifiche di Kubernetes su cui sono pensate per girare le diverse versioni dell'ingress controller.
• Uno scenario relativamente comune, autoinflitto e però fastidioso, in cui alcune organizzazioni si imbattono con EKS è quello in cui assumono un consulente per realizzare una soluzione basata su EKS nel modo più rapido ed economico possibile. Poi, alla fine del contratto, il cluster EKS e i suoi workloads possono restare intatti per anni.

Alla fine qualcuno scopre che la piattaforma EKS impone aggiornamenti. E lo scopre o dopo che qualcosa si è rotto, o quando l'organizzazione assegna a qualcuno il compito di aggiornare i propri cluster EKS all'ultimo minuto, prima di un aggiornamento automatico forzato.

Spesso un engineer si rende conto di aver sottovalutato l'impegno richiesto, perché deve aggiornare più workloads distribuiti sul cluster, oltre al cluster stesso.

• Normalmente non sarebbe un grande problema, ma può essere stressante farlo con una scadenza dell'ultimo minuto. E, se non rispettata, potrebbe causare disservizi in produzione. Tanto più che queste organizzazioni di solito affidano un compito del genere a chi non è esperto di Kubernetes, e i cluster EKS trascurati tendono a essere il risultato di lavori frettolosi mal pianificati: non hanno IaC né documentazione su come siano stati configurati da un engineer che ha lasciato l'azienda più di 2 anni fa.
• Oltre agli aggiornamenti forzati, i nodi EC2 di EKS hanno più scenari in cui i nodi worker devono essere riavviati rispetto a un cluster ECS basato su istanze Fargate.

(I nodi EC2 possono essere ridotti da un cluster autoscaler che fa risparmiare costi come karpenter.sh, che inoltre per impostazione predefinita riavvia i nodi on-demand ogni 30 giorni, in modo che ricevano gli ultimi aggiornamenti per le VM dei worker node EKS.)

• EKS rende inoltre più facile introdurre complessità opzionale sotto forma di karpenter.sh, controller dell'API gateway di Kubernetes, ingress controller e service mesh.
• L'adozione di questi componenti opzionali introduce rischi sotto forma di nuovi modi in cui possono verificarsi guasti, più cose che possono andare male, nuovi scenari di failure mode come misconfigurazioni, aggiornamenti problematici, vulnerabilità della supply chain, vulnerabilità critiche che richiedono aggiornamenti urgenti, riavvii semi-frequenti come funzionalità o breaking change associati agli aggiornamenti.
• Un'ironia è che service mesh come Istio hanno funzionalità progettate per migliorare l'uptime, come la formazione di una mesh multiregionale tra più cluster, logiche di retry e altre funzioni integrate; tuttavia, in pratica non è raro che siano fonti comuni di downtime.
• Una volta che un'app è distribuita e in esecuzione, ECS tende a essere maintenance-free.
• Le configurazioni EKS hanno spesso almeno 3 cluster, ognuno con più componenti, tutti soggetti ad aggiornamenti che, sommati, danno origine a un lavoro di manutenzione inevitabile.
• Per fortuna, molti progressi hanno permesso di ridurre al minimo il lavoro di manutenzione; uno dei principali è EKS Auto Mode, ma anche se non lo si usa, AWS Managed Add-ons e API v1 stabili per ingress e karpenter hanno reso gli aggiornamenti più semplici, rapidi e affidabili.

6. EKS comporta un overhead di manutenzione inevitabile e un ordine di grandezza in più di componenti rispetto a ECS, che non richiede mai manutenzione.

Questi 2 svantaggi, in apparenza minori, di EKS producono effetti di secondo ordine che si traducono in svantaggi significativi in termini di overhead operativo. Per dare un po' di concretezza alla parola "significativi", usiamo come stima approssimativa 2-14 giorni/anno di tempo di engineering dedicato alla manutenzione di EKS.

• Le caratteristiche di ECS lo rendono molto tollerante quando le best practice DevOps comuni non sono note o vengono volutamente ignorate o ridotte al minimo.

Gli admin di ECS possono ottenere affidabilità nonostante pattern poco raccomandati come:

• 1. Implementare workflow che combinano operazioni manuali e automazione parziale, con poca IaC, oppure automatizzare il deployment dei workloads ma non il provisioning dei cluster.

(Può funzionare, perché una volta che un team riesce a far funzionare ECS, tende a continuare a funzionare.)

• 2. Ignorare i benefici di sicurezza derivanti dall'avere più cluster e mettere tutto in un unico cluster ECS.

(Anche se dev e prod sono mescolati in un unico cluster ECS, raramente la cosa danneggia l'affidabilità grazie ai pattern architetturali tipici di ECS, che fanno sì che la maggior parte dei problemi possibili abbia un blast radius ridotto:

È comune che i servizi ECS abbiano il proprio LB gestito da AWS invece di un Kubernetes Ingress Load Balancer condiviso. I container Fargate ottengono VM individuali, il che migliora l'isolamento.)

• 3. Non implementare limiti e richieste di risorse accurati.

(Le istanze Fargate hanno un rapporto di 1 task ECS per 1 VM, il che fa sì che questo sia solo un problema di ottimizzazione dei costi, anziché un problema sia di costi sia di affidabilità.)

• EKS ha abbastanza componenti e complessità da rendere l'implementazione rigorosa delle best practice praticamente un requisito per gli admin che vogliono mantenere i propri cluster EKS affidabili e manutenibili nel lungo periodo.
• La necessità di implementare rigorosamente le best practice ha uno svantaggio significativo.

Le attività legate all'implementazione di manutenzione e best practice impegnano tempo di engineering, e le ore di engineering costano. Peggio ancora, la ricerca delle best practice può portare gli engineer in veri e propri tunnel di yak shaving DevOps.

Lo yak shaving DevOps può essere un'attività perfettamente sensata, ma è anche un potenziale buco nero, perché è difficile distinguere tra ciò che è perfettamente ragionevole, ciò che è potenzialmente eccessivo e ciò che è del tutto inutile.

Vorrei sottolineare la rilevanza di questo aspetto evidenziando che gli admin ECS non solo sono risparmiati dalle attività di routine, ma incontrano anche meno scenari di yak shaving DevOps.

• Qualsiasi team che gestisca EKS arriverà rapidamente alla conclusione di aver bisogno di almeno 2 cluster EKS per ragioni di affidabilità.

È facile scoprire che gli aggiornamenti dei componenti di EKS o le misconfigurazioni possono causare breaking change, e che i problemi a molti componenti come ingress, DNS, CNI, karpenter.sh, service mesh e nodi non integri hanno blast radius molto ampi.

Risulta quindi intuitivamente ovvio che ambienti isolati e test degli aggiornamenti negli ambienti inferiori siano essenziali per l'affidabilità di EKS.

• Una volta che i team EKS si abituano a un workflow di promozione tra ambienti, emerge un'altra constatazione comune:

Testare in un ambiente inferiore è valido solo se gli ambienti inferiori e superiori sono relativamente simili tra loro.

• Molti team EKS investono tempo nello sviluppo di implementazioni rigorose di Infrastructure as Code, automazione end-to-end e pipeline CICD che possano garantire l'allineamento tra ambienti inferiori e superiori.
• Un'altra esperienza comune è che gli ambienti di sviluppo tendono a cambiare più rapidamente, più di frequente e a gestire modifiche manuali. Anche le modifiche manuali "break glass" in produzione per risolvere disservizi e incidenti non sono rare.

Non è quindi raro che i team EKS sperimentino il config drift, ovvero che un ambiente live non corrisponda all'IaC e all'automazione definite in git o in una pipeline CICD.

Garantire che il live corrisponda all'IaC richiede ulteriori implementazioni rigorose di best practice, che di solito comportano un mix di pipeline CICD e implementazioni GitOps.

1. ECS può essere la scelta migliore negli scenari in cui:

• Vuole progettare un'app che debba restare in funzione 2-10 anni con uptime massimo e manutenzione minima.

Supponiamo che abbia un'applicazione che si aggiorna raramente, come un servizio di tooling interno (ad esempio un'applicazione di auditing interno custom) o un'applicazione esposta al pubblico che non causerebbe problemi rilevanti se venisse colpita da una vulnerabilità zero-day di esecuzione di codice remoto. (Grazie a best practice come l'uso di immagini distroless senza shell e diritti IAM ispirati al principio del minimo privilegio.)

In questi casi può aver senso privilegiare il punto di forza di ECS, ovvero un overhead operativo prossimo allo zero, rispetto al punto di forza di EKS, cioè debug più semplice e cicli di feedback più rapidi.

• Ha applicazioni relativamente semplici, distribuisce aggiornamenti agli ambienti solo poche volte al giorno, ha esigenze applicative e architetturali stabili che cambiano raramente, oppure ha intenzione di investire in una pipeline CICD ECS personalizzata che distribuisce solo pattern semplici e che funzionano sempre.

In queste circostanze probabilmente ridurrà al minimo l'esposizione agli svantaggi di ECS, ovvero la difficoltà di debug quando qualcosa va storto e un ciclo di feedback lento.

• Ha un team piccolo, composto solo da sviluppatori, e nessuno dei suoi membri è minimamente interessato o disposto a imparare a implementare in modo rigoroso le best practice DevOps.

In tal caso, ECS è più tollerante (rispetto a EKS) quando le best practice operative sono carenti o ridotte al minimo.

2. Giustificare oggettivamente EKS come la scelta migliore richiede una riflessione un po' più approfondita sui fattori contestuali:

• Sia ECS sia EKS sono soluzioni dai due volti, con benefici e svantaggi che convivono. Ciò detto, può pensare a ECS come più equilibrato, dove benefici e svantaggi sono entrambi relativamente moderati (basso rischio, basso ritorno). EKS, invece, è un caso di benefici più significativi e svantaggi moderati (rischio moderato, ritorno significativo).
• Prima di passare ai benefici di EKS, è prudente partire dagli svantaggi: considerarli in anticipo le permette di affrontare con la giusta predisposizione mentale una domanda che aggiunge prospettiva:

"I benefici che vedo compensano almeno, se non superano, gli svantaggi?"

• 1° svantaggio di EKS: l'adozione di EKS, per avere successo, richiede l'implementazione rigorosa delle best practice DevOps, che a sua volta richiede volontà e un investimento significativo di risorse.

Può richiedere più tempo di quanto molti si aspetterebbero, perché i "problemi DevOps" richiedono spesso "soluzioni DevOps", che a loro volta tendono a dover essere accompagnate da problem transformer prima di poter applicare soluzioni reali.

È anche per questo che i professionisti DevOps a volte si definiscono scherzosamente "yak shaver professionisti". Trasforma un problema un numero infinito di volte e degenererà in un'attività di yak shaving.

(Stimiamo questo investimento iniziale tra 1 e 4 mesi di lavoro di engineering una tantum.)

• Se vuole influenzare positivamente quell'impegno di 1-4 mesi, paghi abbastanza da assumere persone con pensiero critico, capaci di cogliere le sfumature tra soluzioni di problemi e trasformazioni di problemi. Si assicuri che il suo team comprenda la logica e le ragioni alla base del paradosso secondo cui "EKS tende a essere difficile perché è troppo facile".

E favorisca principi e consigli come:

KIS (Keep It Simple), YAGNI (You Aren't Gonna Need It), le API v1 stabili sono sue alleate, i servizi gestiti come l'AWS LB Controller dovrebbero essere preferiti rispetto a Ingress Controller DIY come Nginx (Suggerimento: il primo è una soluzione, il secondo una trasformazione di problema; la scansione delle vulnerabilità di quay.io ha rilevato che un'immagine di nginx-ingress-controller di 6 anni aveva 76 vulnerabilità critiche, una media di 1 CVE critica al mese!) ed EKS Auto Mode merita di essere preso in considerazione.

(Anche Auto Mode è una trasformazione di problema, perché ha alcuni svantaggi come l'introduzione di un effetto black box e l'aumento dei costi; tuttavia, ne vale spesso la pena per cluster greenfield di piccole dimensioni.)

Se segue questi consigli, EKS può rimanere relativamente semplice.

Ricordi: "EKS è difficile quando le persone lo rendono difficile."

• 2° svantaggio di EKS: comporta un grado inevitabile di lavoro di manutenzione.

(Stimiamolo tra 2 e 14 giorni di manutenzione all'anno per 3 cluster.)

• Vale la pena segnalare che EKS Auto Mode, introdotto a dicembre 2024, può essere di grande aiuto nel ridurre al minimo entrambi i 2 svantaggi principali di EKS.
• EKS Auto Mode elimina molto del lavoro preparatorio (per la configurazione di add-on comuni), delle conoscenze prerequisite e della manutenzione continua, e persino di alcune failure mode, dato che è in grado di evitare breaking change utilizzando e automatizzando solo l'upgrade di add-on basati su API v1 stabili.
• Ciò detto, non elimina del tutto la manutenzione e ha alcuni svantaggi: aggiunge dei costi e trasforma EKS in qualcosa di più simile a una black box, peggiorando la facilità di debug.

(Esegue i pod karpenter.sh sui nodi del control plane gestiti, quindi non si possono accedere ai log dei pod karpenter.sh, che spesso servono per il debug di edge case.)

• I prerequisiti sono un altro elemento che EKS Auto Mode non elimina del tutto. Questa pagina linkata indica che dovrà fornire una ingress class specifica per Auto Mode, annotazioni del servizio del load balancer e una storage class che faccia riferimento a un EBS Volume Provisioner specifico per Auto Mode, per poter sfruttare tutte le sue funzionalità.
• È utile sapere fin da subito che migrare da Auto Mode disabilitato ad Auto Mode abilitato è difficile. A prima vista, il portale web di EKS fa pensare che Auto Mode possa essere semplicemente attivato e disattivato.

Tuttavia, se legge questa pagina di Migration Reference, scoprirà che una migrazione in-place è un processo manuale molto faticoso, al punto che spesso è più semplice distribuire un nuovo cluster ed effettuare una migrazione blue-green. La difficoltà della migrazione deriva dal fatto che EKS Auto Mode ha la sua ingress class, load balancer class ed EBS CSI volume provisioner specifici, quindi se prova a fare una migrazione in-place da Auto Mode disabilitato ad abilitato su un cluster preesistente, dovrà ricreare i servizi Kubernetes di tipo Load Balancer, gli oggetti Ingress e tutti i PVC creati prima dell'abilitazione di Auto Mode.

• Considerati questi piccoli problemi e i costi aggiuntivi, non ha senso raccomandare EKS Auto Mode in ogni caso; ciò detto, ritengo che sia spesso una buona scelta per cluster greenfield di piccole dimensioni gestiti da team alle prime armi con EKS. Penso anche che EKS Auto Mode abbia molto senso per chi prevede di avere più di 6 cluster di lunga durata.
• Ora possiamo parlare dei benefici, e il più importante da sottolineare è un risparmio di tempo che ha l'impatto più significativo nel compensare i costi temporali menzionati in precedenza.
• EKS offre un beneficio significativo in termini di debug più semplice e veloce e di cicli di feedback più rapidi e, nelle giuste circostanze (lo sviluppo implica spesso debug continuo), questa caratteristica da sola può bastare a generare un risparmio di tempo sufficiente a compensare i costi temporali e produrre un risparmio netto, in aggiunta agli altri benefici di EKS.
• Ecco alcuni scenari comuni in cui EKS diventa facile da giustificare: la sua app effettua deployment agli ambienti con frequenza tale da giustificare una pipeline CICD il più rapida possibile, ha cambiamenti frequenti, integrazioni complesse, un'architettura orientata ai servizi, sta attivamente migrando da architettura monolitica a service-oriented usando il pattern strangler, oppure presenta complessità tali per cui la possibilità di fare debug facilmente con un ciclo di feedback rapido viene considerata di grande valore.
• Si aspetta che alcune sue app abbiano traffico molto irregolare, e scalare il più rapidamente possibile potrebbe essere un fattore decisivo?

In tal caso, le opzioni di scaling avanzate di EKS (alimentate dall'add-on keda.sh), come lo scaling a zero e lo scaling basato su schedulazione cron, possono diventare vantaggi significativi, oltre a opportunità di risparmio sui costi.

• Qualcuna delle sue app ha un requisito stringente di caricare la configurazione applicativa come file? O necessita di opzioni di storage robuste?
• Ha bisogno o vede un beneficio sufficiente nell'accesso a funzionalità e pattern ingegneristici avanzati come RBAC a livello di cluster, policy as code, GitOps, load balancing avanzato, integrazioni OIDC/Authn/z e, in generale, una customizzabilità che renda facile implementare qualsiasi idea con un'ottima esperienza utente lato engineering?
• EKS può essere un'ottima scelta per progetti in cui i benefici superano i 2-14 giorni/anno di overhead di manutenzione che la sua adozione comporta, e in cui può ottenere il consenso degli stakeholder per l'1-4 mesi di lead time di investimento iniziale necessari a implementarlo secondo le best practice.

3. Le applicazioni stateful sono uno scenario abbastanza diffuso da meritare una discussione basata su regole pratiche:

• EKS rende facile eseguire applicazioni stateful e le supporta bene, ma il fatto che sia facile non significa che sia automaticamente una buona idea. Ho cercato di offrire una visione informata del livello di difficoltà di EKS che si accompagna ai suoi benefici, ma ecco un chiarimento importante: il livello di difficoltà che ho menzionato finora presuppone che si stiano eseguendo applicazioni stateless (e magari qualche app stateful in cui la perdita di dati è accettabile, come nel caso di cache valkey/redis o di strumenti di monitoraggio self-hosted come lo stack di osservabilità PLG di Grafana Labs.)
• Spesso si installano applicazioni stateful su Kubernetes, ma non si considera l'intero ciclo di vita dell'applicazione, inclusi backup automatici, restore automatici, test e integrazioni con la pipeline CICD.

Se si considerano tutti questi aspetti, l'overhead operativo necessario a mantenere una grande affidabilità nel lungo termine è spesso estremamente elevato.

• Abbastanza elevato da indurre a considerare 3 opzioni:
• 1. Considerare di accettare un rischio maggiore di subire diverse ore di downtime circa una volta all'anno, in cambio dell'evitare un overhead operativo significativo, scegliendo deliberatamente di non implementare in modo rigoroso le best practice associate ai workloads stateful.
• 2. Se ha bisogno di un uptime altamente affidabile e di opzioni di disaster recovery più semplici, allora delegare a un servizio gestito costoso può portare a un costo totale di proprietà inferiore.
• 3. Verificare se gli stakeholder hanno la disponibilità e la volontà di investire 1-6 mesi (per ogni singola app/database stateful) di tempo e impegno di engineering dedicato a implementare in modo rigoroso le best practice associate ai workloads stateful, oltre all'aumento dell'overhead di manutenzione.